一文读懂：最近流行的可观察性
两天前，发了一篇文章 十年磨一剑：蚂蚁集团可观测性平台 AntMonitor 揭秘 ，引起大家对可观察性的关注，甚至有同学问：可观察性和监控有什么不同？的确，为了搞清楚一个概念，和一些类似的或相关的概念进行比较，也是很有必要的。那么下面就好好讨论一下这些主题：
什么是可观察性？ 可观察性和监控有什么不同？ 可观察性的应用场景 可观察性带来哪些收益？ 可观察性有什么好的工具？
过去的三年，毫无疑问，"可观察性 "已经迅速火起来。而这个概念提出来，最早可以追溯到2016年3月出版的SRE书中开始使用 "observability"、"observe"、"observation "等词，同年7月开始有了可观察性的定义， 以及到了2017年11月谷歌工程师Jaana Dogan郑重地使用 "observability"。作为风暴来临的预兆，Gregory Poirier在2016年6月发表了题为 "监控已死 "的演讲，讲述了人们试图使用当时的技术来监控生产系统时痛苦的挣扎。17年9月，Cindy Sridharan写了一篇关于可观察性的有影响力的文章 Monitoring and Observability（监控与可观察性）。不到一年，O'Reilly出版了图书：Distributed Systems Observability《分布式系统的可观察性》。
可观察性可以定义为：根据内部系统产生的数据来评估其状态的能力。这个能力使用过程需要在不干预或不与系统互动的情况下审查系统的健康状况，只是在分析了来自系统的输出数据后得出结论。可观察性平台帮助研发/DevOps团队、IT运营团队同时观察或深入了解整个IT基础设施中不同应用和资源的健康和状态。通过从每个系统的数据中获取洞察力，IT团队可以主动发现异常、分析问题并解决问题。
更具体地说，DevOps和IT团队使用日志、度量和追踪（称为可观察性的三大支柱）等输出来衡量系统的可观察性，例如通过评估其属性和模式，我们可以确定各种系统组件的性能如何，然后决定下一步系统是否扩容、是否需要调优。当日志、度量和跟踪等方面的工具检测到异常情况时，它会通知团队，并提供团队所需的数据，以快速排除故障和解决问题。可观察性的三大支柱：
日志。有时间戳的、不可改变的离散事件记录，可以识别系统中不可预测的行为，并提供对出错时系统行为变化的洞察力。一般以结构化的方式读取日志，如JSON格式，以便日志可视化系统可以自动索引并使日志易于查询。
度量。作为监控的基础，会在一段时间内汇总度量指标的结果，这样度量指标会告诉我们一个方法使用了多少内存总量，或者一个服务每秒处理多少个请求，等等。
追踪。在分布式系统中，当一个单独的事务或请求从一个节点移动到另一个节点时，我们通过跟踪能了如指掌。追踪允许我们深入了解特定请求的细节，以确定哪些组件会导致系统错误，如监测通过模块的流量，并找到性能瓶颈。
可观察性起源于控制理论，从一个系统的外部输出了解其内部状态的程度。可观察性使用工具来提升系统监控的洞察力。换句话说，监控是在系统可观察后所做的事情。如果没有某种程度的可观察性，监控是不可能的。
监控是一种收集和分析从单个系统中提取的预定数据的解决方案； 可观察性是一个聚合所有系统产生的所有数据的解决方案。
大多数监控工具使用仪表盘（dashboard）来显示性能指标和使用情况，如IT团队用它来识别或排除IT问题。然而，由于这些仪表盘是由团队创建的，只显示团队可以预见的性能问题或异常情况。这使得监测复杂的云原生应用和云环境的安全和性能问题变得很困难，因为这种情况下遇到的安全问题往往是多方面的、无法预测的。
相比之下，可观察性软件使用在整个IT基础设施中收集的日志、跟踪和指标，主动通知研发团队、IT团队潜在的问题，帮助他们调试系统。监控只是显示数据，但可观察性可以借助基础设施来度量多个应用程序、微服务、服务器和数据库的所有输入和输出。通过了解系统之间的关系，可观察性对系统的健康状况提供了可操作的见解，并在系统出现异常的第一时间检测出问题产生的原因（如漏洞或脆弱的攻击载体）。
可观察性起着更为关键作用。作为 "零信任 "安全模型的一个关键要素，可观察性提供了对用户行为和使用情况的洞察力，这对于保护系统免受未经授权的访问是必要的。持续的日志记录可以洞察系统内的任何异常情况，而不仅仅是那些与健康或性能有关的异常。如果没有可观察性，团队就很难发现问题产生的根源。
DevOps的基础是监控和可观察性，两者缺一不可，两者一起工作，为IT基础设施的健康提供强大的洞察力，当监控提醒团队注意潜在的问题时，可观察性帮助团队检测并解决问题的根本原因，而监控使可观察性成为可能。即使一个特定的终端是不可观察的，监测其性能仍然发挥着重要作用，可以提供更多的信息，以帮助分流和诊断整个系统内的任何问题。当DevOps监控应用程序时，经常同时审查多个指标以确定每个应用程序的健康和性能。收集和显示来自不同IT系统的数据对于DevOps中的程序监控是至关重要的，因为它显示了一个系统或应用程序何时遇到了问题。
云的复杂性要求可观察性，根据调查报告，92%的可观察性领导者（和68%的初学者）通常使用在多个云和企业内部环境中运行云原生应用程序，36%的企业今天使用三个或更多的公共云来运行内部开发的应用程序。因为向混合、多云基础设施的快速发展带来了许多优势，但同时也增加了复杂性，阻碍了可视性，使运营团队疲于应付。
根据每天、每周、甚至每月的函数调用成功次数来确定系统在一段时间内的性能水平。 根据通过云网络的流量模式，识别和排除云服务器负载的故障。 定义系统各个部分如何响应其中一个组件的变化。 从未能及时执行的函数调用中指出异常值。 不时比较账单，以了解获得每个额外资源所产生的使用费。 审查编程模式，以确定代码如何以及何时运行。 密切关注你的应用程序所使用的资源，以确定所消耗的内存数量。 根据性能的转变来确定系统的冷启动。 在比较了应用程序对各种系统属性的反应后，确定其性能能力。 标记出潜在的瓶颈或系统错误，然后利用这些洞察力来建立最佳行动方案，以防止将来再次发生。 在发现组件转换和单个函数调用过程中受延迟影响的痕迹后，注意到微服务交付的滞后性。 建立所有容器或函数调用中的系统错误频率。
研究显示，拥有成熟的可观察性实践的企业获得显著的收益，包括加速开发和部署，更快地发现和解决问题，以及减少停机时间。MTTD (Mean Time to Detect) 降低了一半，MTTR（Mean Time to Repair）降低了70%，只是原来的1/3。
MTTD（平均检测/发现时间）、MTTR（平均解决时间） 监测配置的变化：有多少变化（pull requests）进入监测配置代码库？这些变化多长时间推送一次？ 警报处理：有多少警报是在工作时间之外处理的？哪些团队处理的警报数最多？ 警报分布。警报是否均匀地分布在位于不同地区的团队中？在出现严重程度的问题时，开发人员是否以及何时参与？如果没有，那么为什么？ 假阳性：导致没有行动的警报有多少？什么原因？ 误报：警报的及时性，或者说，系统故障导致没有警报或警报远远晚于要求的时间的情况有多少？ 警报创建：每周有多少新的警报？ 警报确认：有多少警报在约定的时间内得到了回复？ 无法采取行动的警报。有多少百分比的警报被认为是无法采取行动的，因为现场工程师无法立即采取行动？ 沉默的警报：每周处于沉默或压制状态的警报的数量？平均和最长的静默期是多少？有多少新的警报被添加或删除到静默状态，以及静默警报的到期日？ 可用性：警报、运行手册、仪表盘。 - 仪表盘上的图表数量，以及团队能否理解这些图表？ - 每个图表的行数？ - 如何向刚入职的新工程师解释这些图表？ - 人们需要滚动和浏览多少次才能找到信息？ - 工程师能否有效地从警报到运行手册、再到仪表盘进行导航，运行手册是否定期更新？ - 警报的名称是否足够好，能够为工程师指出正确的方向？
随着可观察性和监控概念的发展和普及，现在的云计算为可观察性提供了大量的先进工具，其中一些是在云平台中原生运行的内置工具，而另一些则是由第三方供应商开发的，与各种云服务集成。而且我们可以选择专用的可观察性工具，也可以选择作为监控和可观察性工具的更完整解决方案。
Amazon CloudWatch
CloudZero
Elk
Epsagon Google Cloud’s Operations Suite (/StackDriver) Honeycomb Lightstep OpenTelemetry SolarWinds AppOptics
Splunk